refactor(db): move the authentication store into its own schema - #64

The reaction summary returned the complete member record — student ID, student
email, emergency contact, insurance and allergy details — inside every
reaction's user list as well as in `members`. A member who reacted with three
emoji had those fields serialised four times, so the private data on the wire
grew with the number of reactions rather than the number of members.

The badges only ever rendered names: the client maps that list through
getDisplayName and reads nothing else from it. They now carry a
ReactionParticipant with the identity and name fields, while `members` keeps
the full record the admin table and its CSV export need, including the
emergency contact and allergy details an organiser relies on.

Adds a regression test asserting no private field appears in the badge payload.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Better Auth's tables move to app_auth, and every reference that crossed between
them and the domain is removed, so the authentication store can be lifted into
its own database without touching a domain table. Moving the tables alone would
not have achieved that: a foreign key cannot span databases, and three of them
crossed this boundary, one of which only surfaced when the new assertion ran.

The domain now keeps its own account record in public.app_accounts, holding the
membership link and the application role. role has to live on this side because
the membership trigger authorizes against it, and a trigger cannot read another
database. user_id is stored as a value rather than a foreign key; the reviewer
and community identity references become snapshots too, matching
member_status_history, which already recorded its actor that way.

Losing those foreign keys costs the guarantee that a reviewed user cannot be
deleted. That is the price of the move, and it is now stated in the schema
comments and asserted in the pgTAP suite rather than left implicit.

The auth middleware is the only place that reads both sides. It resolves the
subject from the authentication store and the account from the domain in two
separate queries, so a future split turns the first into a remote call and
leaves the second untouched. The admin views that display an account email do
the same thing in batch instead of joining.

A replay test asserts the tables sit in app_auth, that "user" carries no domain
column, and that no foreign key crosses the boundary in either direction.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The RLS suite still required a reviewed account to be undeletable, which was
the guarantee the dropped foreign key provided. That key crossed into the
authentication store, so the assertion now states what replaced it: the delete
succeeds and the review record keeps the reviewer it was written with.

Caught by the pgTAP job, which the membership work added and which is the only
thing that executes these suites.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Sign-in now requires a public.app_accounts row, which the Better Auth create
hook provisions. If that hook ever fails, or a subject is seeded outside the
flow, the account exists in the authentication store with nothing on the domain
side, and the JWT endpoint and the auth middleware both reject it. The user is
then locked out permanently with no path back except editing the database.

The sign-in path now inserts the row when it is absent, which costs one
statement per sign-in and makes the missing row self-correcting.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…n-payload-pii

…-schema